# 절차형 API (Procedural API)

## 개요

**절차형 API**(Procedural API)는 객체 지향 프로그래밍(OOP)의 대안으로, 함수 호출을 통해 소프트웨어의 기능을 노출하고 제어하는 프로그래밍 인터페이스 스타일입니다. 이 접근 방식은 상태(state)와 동작(action)을 명확히 분리하며, 호출자가 명시적으로 컨텍스트(context)나 상태 정보를 함수 인자로 전달하거나 전역 변수를 통해 관리하는 특징을 가집니다.

C 언어와 같은 저수준 언어에서 널리 사용되었으며, 현재는 OpenGL, GTK+, 그리고 많은 시스템 레벨 라이브러리에서 여전히 핵심적인 설계 패턴으로 자리 잡고 있습니다. 객체 지향적 추상화가 복잡성을 증가시킬 수 있는 환경에서 절차형 API는 직관성, 성능, 그리고 예측 가능한 실행 흐름을 제공한다는 장점이 있습니다.

## 주요 특징 및 동작 원리

절차형 API의 핵심은 **"상태의 명시적 관리"**와 **"함수의 순수한 호출"**에 있습니다. 객체 지향 프로그래밍에서 객체가 자신의 내부 상태를 캡슐화하고 메서드를 통해 이를 조작하는 것과 달리, 절차형 API에서는 상태가 외부에 존재하거나 함수 호출의 결과로 반환됩니다.

### 1. 상태의 외부화 (Externalized State)
절차형 API를 사용하는 라이브러리는 종종 `Context` 또는 `Handle`이라는 추상화된 데이터 구조를 사용합니다. 호출자는 이 핸들을 함수에 전달하여 현재 작업의 컨텍스트를 유지합니다.
*   **예시**: OpenGL의 `glBegin()`, `glVertex3f()`, `glEnd()` 시퀀스. 여기서 `glBegin`은 내부에 렌더링 상태를 저장하는 컨텍스트를 유지하며, 이후의 `glVertex` 호출은 이 컨텍스트를 참조하여 정점을 추가합니다.

### 2. 함수의 순수성 및 예측 가능성
절차형 함수는 일반적으로 입력 인자에 의존하여 출력을 결정하므로, 부수 효과(side effects)가 최소화될 수 있습니다. 이는 디버깅과 테스트를 용이하게 하며, 함수의 실행 순서가 프로그램의 상태에 직접적인 영향을 미친다는 점을 명확히 합니다.

### 3. 전역 상태의 활용
일부 오래된 절차형 API는 전역 변수를 통해 상태를 공유하기도 합니다. 이는 초기에는 구현이 간단했으나, 멀티스레딩 환경에서 동기화 문제를 일으킬 수 있는 단점이 있습니다. 현대적인 절차형 API는 이러한 전역 상태를 피하고, 명시적인 핸들을 통해 컨텍스트를 전달하는 방식으로 진화했습니다.

## 객체 지향 API와의 비교

절차형 API와 객체 지향 API(OOP API)는 동일한 문제를 해결하기 위해 서로 다른 철학을 적용합니다.

| 특징 | 절차형 API (Procedural API) | 객체 지향 API (OOP API) |
| :--- | :--- | :--- |
| **주요 구성 요소** | 함수 (Functions) | 클래스와 객체 (Classes & Objects) |
| **상태 관리** | 외부 또는 명시적 핸들 | 객체 내부 캡슐화 |
| **제어 흐름** | 호출자가 순서를 명시 | 객체가 내장된 로직에 따라 동작 |
| **확장성** | 함수 추가가 비교적 용이 | 상속 및 다형성을 통한 확장 |
| **학습 곡선** | 직관적, 단계별 이해 용이 | 추상화 개념 이해 필요 |
| **오버헤드** | 함수 호출 오버헤드 존재 | 가상 함수 호출 등 런타임 오버헤드 가능 |
| **대표 예시** | C 표준 라이브러리, OpenGL, GTK | Java Swing, .NET Framework, Qt |

## 주요 적용 사례 및 예시

### 1. OpenGL (그래픽스 프로그래밍)
OpenGL은 절차형 API의 가장 대표적인 예입니다. 개발자는 `glCreateShader`, `glCompileShader`, `glLinkProgram` 등의 함수를 순차적으로 호출하여 셰이더 파이프라인을 구성합니다. 객체 지향적 접근이라면 `Shader` 클래스의 `compile()` 메서드를 호출하는 형태가 될 수 있으나, OpenGL은 상태 머신(State Machine) 모델을 기반으로 함수 호출이 전역 렌더링 상태에 영향을 미치도록 설계되었습니다.

```c
// OpenGL 절차형 API 예시
GLuint shader = glCreateShader(GL_VERTEX_SHADER);
const char* source = "#version 330 core...";
glShaderSource(shader, 1, &source, NULL);
glCompileShader(shader);
```

### 2. GTK+ (그래픽스 사용자 인터페이스)
GTK+는 C 언어로 작성된 GUI 툴킷으로, 절차형 API를 사용합니다. 위젯(widget)을 생성하고 속성을 설정할 때 객체를 반환하고 이를 함수 인자로 전달합니다.

```c
// GTK+ 절차형 API 예시
GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), "Hello World");
gtk_widget_show(window);
```

### 3. POSIX 시스템 호출
리눅스 및 유닉스 시스템 프로그래밍에서 파일 입출력, 프로세스 관리 등은 대부분 절차형 함수(`open`, `read`, `write`, `fork`, `exec`)를 통해 제공됩니다. 이는 운영체제의 커널 인터페이스가 효율성과 직결되도록 설계되었기 때문입니다.

## 장단점 분석

### 장점
*   **간결성과 직관성**: 복잡한 객체 그래프를 생성하지 않고도 필요한 기능만 함수 호출로 쉽게 사용할 수 있습니다.
*   **성능**: 가상 함수 호출이나 객체 생성/소멸 오버헤드가 없어, 고성능이 요구되는 시스템 프로그래밍에 적합합니다.
*   **유연성**: 함수를 조합하여 새로운 동작을 쉽게 정의할 수 있으며, 언어의 제네릭성이나 템플릿에 덜 의존합니다.
*   **호환성**: C 언어와 같은 널리 쓰이는 언어와 자연스럽게 통합되며, 바인딩(Binding)이 비교적 단순합니다.

### 단점
*   **상태 관리의 복잡성**: 상태가 함수 외부에 있으므로, 호출 순서나 컨텍스트 관리 실수가 치명적인 버그로 이어질 수 있습니다.
*   **재사용성 부족**: 객체 지향적 상속이나 컴포지션 패턴을 활용하기 어려워, 코드 재사용성이 낮을 수 있습니다.
*   **확장의 어려움**: 새로운 기능을 추가할 때 기존 함수 시그니처를 변경하거나 새로운 함수를 추가해야 하므로, API의 일관성을 유지하기 어렵습니다.
*   **디버깅의 어려움**: 상태가 여러 함수에 분산되어 있을 때, 문제의 원인을 추적하기가 객체 지향적 접근보다 어려울 수 있습니다.

## 결론 및 현대적 관점

절차형 API는 객체 지향 프로그래밍이 주류가 되기 전부터 존재해 왔으며, 여전히 시스템 프로그래밍, 임베디드 시스템, 그리고 고성능 그래픽스 분야에서 필수적인 도구입니다. 현대 소프트웨어 개발에서는 절차형 API와 객체 지향 API를 혼용하는 하이브리드 접근 방식이 일반적입니다. 예를 들어, C++에서 OpenGL을 사용할 때는 절차형 OpenGL 함수를 호출하되, 이를 래핑(Wrapping)하여 클래스 기반의 추상화된 인터페이스를 제공하는 경우가 많습니다.

개발자는 프로젝트의 요구사항(성능, 유지보수성, 팀의 전문성 등)에 따라 절차형 API와 객체 지향 API 중 적절한 스타일을 선택하거나 조합하여 사용해야 합니다. 절차형 API는 단순함과 효율성을 추구할 때 강력한 대안이 될 수 있으며, 그 본질을 이해하는 것은 다양한 프로그래밍 패러다임을 포용하는 데 중요합니다.

## 참고 자료 및 관련 문서

*   [객체 지향 프로그래밍 (Object-Oriented Programming)]
*   [함수형 프로그래밍 (Functional Programming)]
*   [OpenGL 프로그래밍 가이드]
*   [C 표준 라이브러리 (C Standard Library)]
*   [API 설계 원칙 (API Design Principles)]